On 4/1/21 12:45 PM, Ive wrote:
> Am 4/1/2021 um 16:53 schrieb William F Pokorny:
...
>>
>> (a) - Ponder one. Is the srgb adjustment valid outside the [0..1] 
>> range? It works, but you get essentially a pow(>1,2.2) result which 
>> doesn't correspond to any 'display adjustment' or 'web visual color'.
>>
> The sRGB transfer function is /per definition/ only valid in the 
> [0.0..1.0] range. Negative values (i.e. out of gamut values) do make 
> only sense within a linear color space and the same goes for values 
> above 1.0 (i.e. HDR values).
> 
...
> 
...
>>
>> Overall, what I'm thinking is srgb makes sense where we are in fact 
>> defining colors within the srgb visual/display color space. Further, 
>> that the old linear encoding is better where any of the incoming 
>> channels values are larger than 1.0(c). I think it likely better to 
>> have the parser force rgb* use over srgb* where any of the channel 
>> values are outside expected srgb space(d).
>>
>> (c) Or less than 0.0 / negative color channel values.
>> (d) And thinking warnings on filter/transmit values >1.0 or <0 as 
>> there are useful tricks with odd f/t values.
>>
>> Thoughts?
> 
> I did argue a bit with Christoph at the time he was making the 
> suggestion for introducing the srgb keyword.
> I was against it and my arguments where pretty much the problems you are 
> mentioning here.
> Christoph's argument was mainly that whole purpose of the srgb keyword 
> is to make life easier for people who use a color picker within any 
> paint software to select their colors out of pictures.
> Well, reality is that people are using it because they think it somehow 
> solves all gamma related problems -  but without actually understanding 
> what it does.
> But anyhow, I never did use this keyword myself so frankly I don't care 
> much.
> 

Thanks. I was hoping you'd answer. :-)

I think there is a place for the srgb* keywords. I find them useful.

With your confirmation on the range for the sRGB transfer function, the 
implementation allowing the keywords to 'run' outside of intended srgb 
value range was a mistake. I'll be updating my povr branch's srgb* 
keywords to fail during parse on invalid input channel values.

Rambling... With color vector math, we have long had exposures to misuse 
/ naive use. Have done and continue to do my own share of stupid 
stuff... :-)

Bill P.

Post a reply to this message